%************************************************
\myChapter{Methodology and Technology}\label{ch:methodology}
%************************************************
\section{Methodology}
One of the main goal of the project has been to generate the code for the visual editor from a model describing the OGSA-DAI workflow. Usually models are used to achieve a better understanding of the problem and for documentating, but they can also be used to generate automatically code. The idea behind this concept is build the model at the begin of the development life cycle,  improving the code quality (generating automatically the code prevents bugs), the productivity (the model can be used for several purpose), and hiding the complexity.

The methodology used to achieve the goal, is called Model Driven Development (MDD). The section~\ref{sec:model} introduces the concepts of \textit{model and meta-model}, meanwhile the section~\ref{sec:mdd} gives a brief overview of MDD and the key technologies related to it.

\subsection{Model and meta-model}\label{sec:model}
A model is an abstract description of a problem that hides information about some aspects of it. A good definition of model is provided by \cite{bezivin2001tpd}: 
\begin{quote}
	A model is a simplification of a system built with an intended goal in mind. The model should be able to answer questions in the place of the actual system.
\end{quote}
The idea behind a model is that it should be easier to use than the original system in such a way that many details from the source system are abstracted out, and only a few are implemented in the target model. A model allows the domain problems to be described by using terms that are familiar to domain experts rather than term that only familiar to IT experts.

A specific model can be retrieved from the problem domain using a specific meta-model. Different models of the same system can be observed and manipulated, and each model can be represented by a different meta-model\cite{bezivin2001tpd} define a meta-model as:
\begin{quote}
	A meta-model is the explicit specification of an abstraction. In order to define the abstraction, the meta-model identifies a list of relevant concepts and a list of relevant relationships between these concepts.
\end{quote}

A  metamodel specifies the set of elements that should be considered while creating a model, and the scope of what may be defined in a model, what elements may be contained in the model and how these elements relate to each
other. Metamodel abstracts from specifics of implementation technologies, it focuses on defining domain concepts.

\subsection{Model driven development}\label{sec:mdd}
Model-Driven Development (MDD), an Object Management Group (OMG) trademark\footnote{See OMG Trademarks \url{ , http://www.omg.org/legal/tm_list.htm}}, is a software development approach that focuses on models and model transformations. The aim of the MDD is to raise the level of abstraction with tools and to provide higher level of automation. One of the approach that implements the MDD specification is \ac{MDA}.

The \ac{MDA} \citep{mda2001omg} has been defined in 2001 by the OMG, to provide a new paradigm of software development. \ac{MDA} is based on other OMG's technologies: Unified Modeling Language (UML) \citep{uml2003omg}, the Meta Object Facility (MOF)\citep{mof2003omg} and XML Metadata Interchange (XMI).
The MDA specification covers the complete life cycle of a product from the design to deployment, integration, and management, and it was designed with various goals in mind: portability and reusability, cross-platform interoperability, platform independence, domain specificity, productivity.

\begin{figure}[htb]
	\centering
	\includegraphics[scale=0.55]{gfx/model_driven_architecture}
    	\caption{Model Driven Architecture}\label{fig:model_driven_architecture}
\end{figure}

The Figure~\ref{fig:model_driven_architecture} shows that MDA defines a clear distinction between Platform Inde-
pendent Models (PIM) and Platform Specific Models (PSM). The software development process can be divided in three steps:
\begin{aenumerate}
	\item The Platform Independent Model is designed, using modelling concepts which are not platform specific. The PIM is a pure UML model, with constraints specified in the Object Constraint Language (OCL).
	\item The Platform Specific Model, containing additional UML models, is generated. The PSM represents an implementation of the system under design which can run on the target platform. The transition between PIM and PSM should typically be facilitated using automated model transformation technology.
	\item The application code is generated from the Platform Specific Model. In order to minimise the manual coding, that is slow and error-prone, the code generation should be as extensive as possible.
\end{aenumerate}


The domain-specific language used by MDA to define modelling languages is MOF: a MOF model is a definition of an MDA modelling language. MOF defines also how an MDA modelling language can be serialized into an XML document, and is 
primarily a technology for the storage of conceptual models and interchanging them using another language called 
XMI.

XML Metadata Interchange is a standard that connects MOF  with XML, and defines a simple way to specify model objects in XML documents. An XMI document's structure closely matches with of that of the corresponding model, with the same names and an element hierarchy that follows the model's containment hierarchy. As a result, the relationship between a model and its XMI serialization is easy to understand.\cite{budinsky2003emf}
%XMI defines production rules for generating XML schemas from MOF metamodels and it can be used to generate XML-based %serialization for the language. XMI is strongly coupled to the metamodel of the target language, thus
%the interchange format cannot be changed unless the metamodel is changed.

\section{Technology}
The technologies used to follow the MDD methodology, belong to Eclipse Modeling Project\footnote{See \url{http://www.eclipse.org/modeling/}}, and they are:
\begin{itemize}
	\item \ac{EMF}
	\item \ac{GMF}
\end{itemize}

\subsection{\acl{EMF}}
EMF is an Eclipse framework for Ecli modeling and code generation. It was started as MOF implementation and represent and enhancement of the MOF2.0 specification.  Models can be specified using annotated Java, XML documents, XMI or ecore file and then they can be imported into EMF. From a model specification EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and editing model and a basic editor.
EMF includes its own metamodel called Ecore which is used for describing models and runtime support for models. Ecore metametamodel is shown in Figure~\ref{fig:ecore_metamodel} and it is compliant with MOF. The runtime support includes notification, persistence and XMI serialization.

\begin{figure}[htb]
	\centering
	\includegraphics[width=1\textwidth]{gfx/ecore_metamodel}
    	\caption{Ecore metamodel}\label{fig:ecore_metamodel}
\end{figure}

Fom an EMF model, a set of Java classes for the model and a tree based editor can be generated. The generated classes provide basic support for creating/deleting model elements and persistency operations like loading and saving. Relations between EMF model classes are handled by special EMF lists, extending the Java list classes.

\subsection{\acl{GMF}}
The Eclipse Graphical Modeling Framework (GMF) started as an Eclipse Technology subproject with the objective ot provide a generative component and runtime infrastructure for developing graphical editors in Eclipse. GMF introduced the notion of the ``mapping metamodel'', specifying a generative bridge between conceptually separated
diagram (concrete syntax) and logical model (abstract syntax) layers. It uses EMF and GEF in a generative manner to create domain-specific editors without writing source code.
Figure\ref{fig:gmf_overview} shows  the main elements that are used during GMF-based development
\begin{figure}[htb]
	\centering
	\includegraphics[scale=0.5]{gfx/gmf_overview}
    	\caption{GMF overview}\label{fig:gmf_overview}
\end{figure}
The step to follow to create a visual diagram in GMF are:
\begin{enumerate}
 	\item Domain model: using EMF it's necessary to define the abstract syntax(metamodel) of the diagram. This metamodel should define the language concepts and relationships.
	\item Graphical definition: is used to define the graphical elements that will be displayed. The graphical element are not directly related with the elements of the Domain model (for which they provide a visual representation): the linking will take place in a different step, using a mapping model 
	\item Tooling definition: This is an optional component, and is used to define control elements of the GUI like the palette, menus, toolbars, etc.
	\item Mapping model: This is the central point in GMF development, and it is used to link all together the previous models. Taking as input the domain model, the tooling definitions and the graphical model it produces as output the  final model, called generation model.
	\item Generator model: this model is used to define the details about the final diagram code, and gives the possibility to obtain as final result an eclipse plugin or a standalone Rich Client Platform (RCP) application
\end{enumerate}

\subsection{Rich Client Platform}
The methodology adopted to develop the application, made possible to focus how to describe and model the problem. The EMF and GMF are in charge of generating automatically the code, including the packages that are implementing the UI. Potentially the developer will be never involved with issues about 

%*****************************************
%*****************************************
%*****************************************
%*****************************************
%*****************************************
